![(レポート)SRE Tech Talks 第1回 #sretalks](https://devio2023-media.developers.io/wp-content/uploads/2013/09/icatch.png)
(レポート)SRE Tech Talks 第1回 #sretalks
本記事は2016年7月25日(月)に開催された SRE Tech Talks #1〜Site Reliability Engineeringにまつわるエトセトラ)〜 のレポート記事です。
SREは”Site Reliability Engineering”の略です。SREの概念を広めたGoogleでSREチームを作った Ben Treynor Sloss は SRE のことを次のように定義しています。
"Fundamentally, it's what happens when you ask a software engineer to design an operations function”
日本で SRE の名前が広まったのは Mercari の2015年11月18日の次のブログがきっかけとよく言われます。
インフラチーム改め Site Reliability Engineering (SRE) チームになりました
本レポートでは、イベントの中から、筆者が特に面白いと思った、次の2発表を中心にレポート致します。
- 株式会社メルカリ - SRE 長野雅広 @kazeburo Hybrid Server Architecture
- 株式会社はてな システム開発本部 システムプラットフォーム部 倉知 真太郎 @dekokun サービス信頼性向上のための事例紹介@はてな
Hybrid SERVER Architecture in Mercari
トップバッターは会場を提供しているメルカリ @kazéburo さんによる発表です。
Mercari の SRE メンバー
Mercariのエンジニアブログで「インフラチーム改め Site Reliability Engineering (SRE) チームになりました」のブログエントリを書いてから、日本で”SRE”という用語が定着してきた
SRE は Google が発祥
OperationsとSoftware Engineeringをやっている
MercariでのSoftware Engineering 例
- Gaurun(プッシュ通知サーバ)の開発
- ngx_luaのBalancer拡張
- ChatOps
- Mackerel Plugin開発
Infrastructure
前提として、サーバー群は日本とアメリカにある。
イギリスも展開予定。
日本:さくらインターネット
さくらインターネットの専用サーバ(Metal as a Service)とクラウド
- 2コアで済むようなサーバであればクラウドを利用
- MySQLは専用サーバでioMemoryがささっている
アメリカ:AWS
AWS US West(Oregon)
- 基本的に全部EC2
- マネージド・サービスは基本的に使わない
特徴
クラウドと物理サーバというHybrid Architectureでありながら構成がほとんど同じ理由
アプリケーションコードの複雑性(クラウド・物理の分岐など)を排除したい。
複数サイトあるときに全く同じ構成にして条件分岐を極小にするの、運用に超効くので絶対守ったほうがよい #sretalks
— tagomoris (@tagomoris) July 25, 2016
クラウド・物理それぞれで固有のベースセットアップを済ませたら、そこから上は同じようにプロビジョンしたい
クラウド・物理と同じアプローチでスケールさせたい。クラウドのマネージドサービス(たとえば AWS RDS)を使うと、カスタマイズ出来る範囲が狭くなってしまう。
技術の変遷
最初から、マネージド・サービスを使わず、サーバを並べるアーキテクチャーだったわけではない。
たとえば、スキーマ変更の際、スレーブから先にスキーマ変更し、最後にレプリケーションで利用するbinlogを無効にしてマスターでスキーマ変更する Rolling Schema Upgrade(RSU) を採用したいが、RDS MySQLでは使えない、というような制約が積み重なり、マネージドサービスからサーバ中心のアーキテクチャ(Server Architecture)に変遷してきた。
Server Architectureの理由
新しい技術への対応、スケーラビリティの制御、細かいチューニングと言った理由もあるが、さくらの専用サーバ・クラウドを利用してる日本で大規模に運用しているので、同じ手法をUSでも適用したい、というのが大きい。
AWSのマネージドサービスに統合しない理由
サーバから自分たちで最適化を積み重ねることで、クラウドのマネージドサービスより高い信頼性をSREが提供できる
ただし、信頼性の提供が難しかったり、どう考えてもクラウドのほうが便利な場合はクラウドサービスを使う。
利用しているクラウドサービス例
- Akamai(CDN)
- Google BigQuery
- Mackerel(Monitoring)
- SendGrid(メール送信。USだけ)
- Route53(DNS)
- S3(Storage)
Consul
サーバアーキテクチャを支える技術としてConsulの紹介。
Mercariでは以下の用途で利用。
- サービスディスカバリ
- サービスのチェックスクリプトをいろいろ書ける
$consul maint
を使うと、即時にサービスから外すことができる。再起動をしても、メンテナンスモードは維持される。ELBは時間がかかる。
- 設定の配布
- 2016/08/1のConsul Casual Talks #1 で @cubicdaiya さんが発表。
- 分散ロック
Mackerel
3年前に Mercari がサービス開始されてから Zabbix をずっと使ってきた。 最近 Mackerel に移行した。
移行の背景
- JP/USそれぞれでZabbix サーバをインストールしており、バージョンが微妙に違っていた。
- 監視ホストを追加するとき、管理画面からポチポチやっていると、設定が微妙に異なったりしていた。
これらを整理するために、より信頼性の高い Mackerel に移行した
JP/US で統合的に監視できるようになった。
2016年5月12日には Mackerel Meetup #7 Tokyo を Mercari オフィスで開催した
まとめ
- Mercariのシステムは物理サーバを中心としたJP環境とかそうサーバを中心としたUS環境のHybrid Architecture
- サーバを中心とした構成で、SREが高い信頼性を提供
- Hybrid Server Architecture を支える技術として Consul や Mackerel 等がある
Q&A
# SREチームにとって、ダウンタイムの管理は重要。どうやってダウンタイムを計測している?
ダウンタイムの目標値はあるが、それほど数値にこだわっているわけではない。
Mackerel にはダウンタイムを積算する機能はないので、自分たちで手計算してスプレッドシートで管理するといったことはやっている。
なお pingdom はダウンタイムを計測出来るようです。
# RDS などのクラウドサービスを使わず、自分たちで頑張るServer Architectureを押しているのに、ZabbixをやめてMackerelにした理由は?
監視システムは自分たちのコアコンピタンスではない。
SMTPサーバを管理したい人はどこにもいないから、SendGridを利用している。
Zabbixの運用もサーバ台数が100台を超えてくると大変になるので、外部サービス(Mackerel)にまかせると、自分たちのより重要なサービスにリソースをさける。
印象
マネージド・サービスより高水準なサービスをサーバーアーキテクチャーで提供できているのは、優秀なSREエンジニアが6人もいるMercariだからこそです。
普通のインフラエンジニアが少数しかいない環境では、素直にクラウドのフルマネージドサービスを活用しましょう。
今でこそEC2だらけのAWSインフラも、当初はマネージドサービスで運用していました。
Introducing in-house PaaS
スマートニュース株式会社でSREのマネージャーをやっている 尾形暢俊さんによる発表です。
はてなでの サービス信頼性向上のための 取り組み事例 by dekokun
続いて、はてな東京オフィスでWebオペレーションエンジニアをやっている id:dekokun さんの発表です。
SREってそもそもなに?
イベント名は”SRE tech talk”だが、SREが何なのか知らなかった。 社内で”Site Reliability Engineering”(以下「SRE本」)の輪読会を始めた。
伝統的には
- インフラ担当の”Opsエンジニア”
- 開発担当の”Devエンジニア”
の2種類の職種があるが、はてなでは両者の境界はあいまい
サービス向上のために取り組んでいることの紹介
DevとOpsの対立
SRE本では新しい機能を試したい Dev と システムを安定させたい Ops の対立が、あるある問題として取り上げている。
はてなでは両者は協力体制にある。
Opsエンジニアがサービスコードをいじり、DevエンジニアがChefをいじる
協力体制事例:DBの転送量削減
クライアント↔DBの通信量が限界に近づいてきた時に、
SRE本では、従来のOpsエンジニアは可用性を守るために素早いデプロイなどに対立するとあるが、Webサービスを提供する側からすれば、問題があった時にさっさとデプロイしないとサイトの可用性は守れない。
OpsがMySQLサーバとの通信データを圧縮するオプションを有効にしたり(DBD::mysql の mysql_compression=1)、 DevとOpsが強力してMySQLサーバとの通信量が増える原因を突き止め、Devが通信量を減らすようアプリ改修したりする。
エンジニアが参加する週次の社内勉強会では、Dev/Opsそれぞれの仕事の内容を発表するなどして、相互理解の助けになっている。
はてなでは日々OpsエンジニアとDevエンジニアが協力しつつ、サービスの信頼性向上への取り組みを行っていっている
コードと検証によってサービスの信頼性を向上させる話
SRE本によると、GoogleのSREチームはオペレーション業務は50%に止め、残りはコーディングに当てる。 はてなのOpsチームは、50%程ではないにしてもコーディングでインフラのエンジニアリングをしている。
ミドルウェアの設定ファイルの構文チェッカをさくっと書いたり、インフラ構成を変更するプログラムをさくっと書いたりする
目指すべきシステムの姿について
機械ができることは機械にやらせ、人間は人間にしかできないことに注力する
具体例として はてなの自動復旧システムが紹介されました。
例えば、Xenの上で作られた、サービスにおいて、DomU で動作しているサービスがヘルスチェックに引っかかったら、DomU をOSごと作りなおす。 ヘルスチェックにバンバン引っかかっても、作りなおせば良い。
勝手に復活するやつは実際にはごく一部のどうしようもないところだけいれてます #sretalks
— ゆううき (@y_uuk1) July 25, 2016
まとめ
Dev エンジニアと Ops エンジニアが協調してよりよりサービスを作る。 機械にできることは機械にやらせる。
Q&A
AWS Elasticache Redis のようなマネージド・サービスを使わない理由は?
データセンターと同じように運用したい。 (Mercariと同じ理由)
金曜日にリリースしない理由は?
業務時間内で障害対応できるように、夕方以降や土日のリリースを避ける。
DevとOpsの領域は?
曖昧でエンジニアの興味範囲次第。
実践!マイクロサービス化
最後は Wantedly株式会社 リードエンジニア 相川直視 @awakia さんによる発表です。
個人的印象
終始、楽しそうに発表する姿が印象的でした。
はてなの人、とても楽しそうな話し方が印象的で良い職場感すごい感じた。 #sretalks
— Hiroaki Sano (@la_luna_azul) July 25, 2016
採用目的のイベントではありませんが、エンジニア採用という観点では、非常によい発表だったのではないでしょうか。
なお、はてな様は近日中に自社イベントを開催されるそうです。
SRE の採用について
イベント全体を通しての最後の質問は SRE の採用についてでした。
直球です。
なんでもこなしてしまう SRE メンバーを雇うハードルは非常に高いのではないかと?
質問「SRE雇えるんすかwww」 #sretalks
— Ryuta Kamizono (@kamipo) July 25, 2016
各社の回答をまとめます。
メルカリ
- メルカリは積極的に採用を続けている。
- 知り合い経由のオフラインでの採用に力を入れている。
- 全部で6人いる。
- SREは見方によってはコストセンターになる
- 事業責任者や経営者の理解が必要。
- SREからも理解してもらうように働きかける事が必要。
- 今回の様なイベントを今後も続けることで、SREの活動を世に広め、採用にも繋がるのではないか。
Wantedly
- インフラ要項の募集要項に「SRE」のキーワードを増えると、募集が増える傾向がある。
- 少しバズっているのかもしれない。
はてな
- はてなにはSREという名前はない
- Webオペレーションエンジニアを積極採用中。
- 東京に拠点があったり、そもそも、採用募集中であることがいまひとつ認知されていない。
- 自社セミナーで認知度を上げるようにしている。
スマートニュース
- SREチームができたのは2016年1月。
- その時から、SREチームはずっと2人。
- 募集をかけているが、メンバーは増えていない。
- SREを名指しで募集してきた人は非常に少ない。
- 本気で採用するなら、身内から引っ張ってくこないかもしれない。
- そもそもスマートニュースは面接の数が多く、内定率は非常に少ない。認知度がまだ低いのかもしれない。
まとめ
私自身は SRE をやる立場にはありませんが、著名サービスを運用する各社のSREチームから生々しい話が聞けて、非常に楽しめました。
SRE チームの職務と言っても、従来のインフラ、オペレーション、DevOps エンジニアのそれと大きく異なるわけではないという印象を持ちましたが、今後は SRE の観点・価値観からサービスのオペレーションがより洗練されていく印象を持ちました。
まずは SRE 本 “Site Reliability Engineering - How Google Runs Production Systems” を読み、SRE の思想を学びたいと思います。
なお、Mercariのオフィスは株式会社ポケモンと隣接しています。
登壇者の皆様、お疲れ様でした!